Feature/implicit deregistration #107

YouShengLiu · 2023-08-17T10:17:57Z

Implement a callback function to handle the Deregistration Notify form UDM which is step 14 of the general registration procedure.

* Add TimeZone field in the AMFContext.

ianchen0119 · 2023-08-24T05:30:11Z

internal/sbi/httpcallback/api_handle_dereg_notification.go

+
+			if smContext.AccessType() == deregData.AccessType {
+				var problemDetails *models.ProblemDetails
+				problemDetails, err = consumer.SendReleaseSmContextRequest(ue, smContext, nil, "", nil)


SendReleaseSmContextRequest() needs to read the attribute of the ue, it will occur the concurrent read/write if another ngap/nas message for the same ue is sent to AMF.
Please help to check do we need a mutex lock here.

Moreover, it seems like the behavior of AMF in this case is the same with gmm_common.RemoveAmfUe(amfUe, false).
@iamelisahi @YouShengLiu

SendReleaseSmContextRequest() needs to read the attribute of the ue, it will occur the concurrent read/write if another ngap/nas message for the same ue is sent to AMF.
Please help to check do we need a mutex lock here.

SendReleaseSmContextRequest() will only use the ue.TimeZone and smContext.
Since the smContext is stored in ue.SmContextList and protected under the sync.Map, we can leave it alone.
However, the ue.TimeZone is not protected, it may need mutex lock to protect.

Moreover, it seems like the behavior of AMF in this case is the same with gmm_common.RemoveAmfUe(amfUe, false).

Yes, it is very similar but there are still some differences.

According to the TS 29.503 - Table 6.2.6.2.7-1: Definition of type Amf3GppAccessRegistrationModification - backupAmfInfo:

This IE shall be included if the NF service consumer is an AMF and the AMF supports the AMF management without UDSF for the Modification of the BackupAmfInfo.
The UDM uses this attribute to do an NRF query in order to invoke later services in a backup AMF, e.g. Namf_EventExposure

We think we should provide the BackupAmfInfo but the UeCmDeregistration() didn't.
Should we need to modify UeCmDeregistration(), e.g. add one more parameter to decide if it needs to put the BackupAmfInfo into Amf3GppAccessRegistrationModification?

@YouShengLiu

Yes, it is very similar but there are still some differences.

Is it possible to reuse the duplicated part?

We think we should provide the BackupAmfInfo but the UeCmDeregistration() didn't.
Should we need to modify UeCmDeregistration(), e.g. add one more parameter to decide if it needs to put the BackupAmfInfo into Amf3GppAccessRegistrationModification?

I think you are right, please help to fill the BackupAmfInfo.

Does spec mention to use old amf as the backup amf? I think it's strange to notify UDM that the backup amf of e.g. amf1 is amf1 itself😂 Backup AMF may be a pre-config field to this AMF's config in my opnion.

Spec didn't mention using old AMF as the backup AMF directly. I was thinking that the old AMF could be one of the backup AMFs when the new AMF is serving the UE.
I checked the data stored in the database, the serving AMF was the new AMF, and the old AMF became the backup AMF:

{ "_id": { "$oid": "650059c26b8b38f7f8ab93dc" }, "ueId": "imsi-2089300007487", "amfInstanceId": "faf609ad-2cbd-4082-bf41-7a554e4aa626", "imsVoPs": "HOMOGENEOUS_NON_SUPPORT", "deregCallbackUri": "http://127.0.0.19:8000/namf-callback/v1/amf-implicit-deregistration/imsi-2089300007487", "initialRegistrationInd": true, "guami": { "amfId": "cafe01", "plmnId": { "mcc": "208", "mnc": "93" } }, "ratType": "", "backupAmfInfo": [ { "backupAmf": "AMF", "guamiList": [ { "amfId": "cafe00", "plmnId": { "mcc": "208", "mnc": "93" } } ] } ], "purgeFlag": true }

I think it's strange to notify UDM that the backup amf of e.g. amf1 is amf1 itself😂 Backup AMF may be a pre-config field to this AMF's config in my opinion.

I agree that using pre-config is a better solution.

ianchen0119

As we discussed,
AMF should not send UECM_DEREG to UDM when AMF received the dereg_notification from UDM.

ss920386 · 2023-09-12T08:53:06Z

internal/sbi/producer/ue_context.go

-
-		gmm_common.RemoveAmfUe(ue, false)
+		// TODO: Currently only consider the 3GPP access type
+		if !ue.UeCmRegistered[models.AccessType__3_GPP_ACCESS] {


Will 3gpp and non-3gpp have different behavior here? I think a better implementation here is to remove the context according to different access type (which is specified during context transfer procedure), but I understand it seems that currently we can only remove the complete AmfUe context (3gpp+non-3gpp). In this case, I don't quite understand why non-3gpp is excluded here😂

Because we are not sure how to deal with the non-3GPP case, we temporarily considered the 3GPP case.

ss920386 · 2023-09-12T09:08:06Z

internal/sbi/httpcallback/api_handle_dereg_notification.go

+	// TS 23.502 - 4.2.2.2.2 General Registration
+	// The old AMF should clean the UE context
+	// The AMF also unsubscribes with the UDM using Nudm_SDM_Unsubscribe service operation.
+	err = gmm_common.PurgeSubscriberData(ue, deregData.AccessType)


For SDMUnsubscribe in PurgeSubscriberData, 23.502 4.2.2.2.2 step 14.e mentioned that
If old AMF does not have UE context for another access type (i.e. non-3GPP access), the Old AMF unsubscribes with the UDM for subscription data using Nudm_SDM_unsubscribe
Should this be checked here?

I followed the TS 23.502 - 4.2.2.3.3 Network-initiated Deregistration,

[Conditional] If the Deregistration procedure is triggered by UDM (Step 1), the AMF acknowledges the Nudm_UECM_DeRegistrationNotification to the UDM. The AMF also unsubscribes with the UDM using Nudm_SDM_Unsubscribe service operation.

However, it seems that we should also consider whether old AMF have UE context for non-3GPP access.
I am not sure which elements in the AmfUe context belong to non-3GPP, maybe you can enlighten me. :)

Generally, contexts in AmfUe without map[models.AccessType]Xxx are contexts shared by both 3gpp and non-3gpp. In other words, contexts with map[models.AccessType]Xxx may indicate the existance of non-3gpp contexts.
I think one way to judge whether amf has non-3gpp access may be checking the existence of ameUe.State[N3GPP], but that requires refactoring for amfUe.init() since it initializes ameUe.State[N3GPP] with Deregistered state instead of nil.😂

I think this can be added as TODO comment if that may take time to achieve currently, thanks.

According to R15 TS 23.502 - 4.2.2.2.2 - 14e,

The Old AMF unsubscribes with the UDM for subscription data using Nudm_SDM_unsubscribe.

I think we can add a TODO comment here.

ss920386 · 2023-09-12T09:15:29Z

internal/sbi/httpcallback/api_handle_dereg_notification.go

+	err = gmm_common.PurgeSubscriberData(ue, deregData.AccessType)
+	if err != nil {
+		logger.CallbackLog.Errorf("Purge subscriber data Error: %v", err)
+	}


Original RemoveAmfUe at dereg when notifyNf is true also considers AMPolicyControlDelete. Should AMPolicyControlDelete be included here according to TS 23.502 4.2.2.2.2 14d?

I don't find the description in R15 - TS 23.502 - 4.2.2.2.2 - 14d and I am not sure if we need to delete AmPolicy here.
Based on my understanding of implicitly deregistering AMF, the goal of it is only to remove the UE context from old AMF rather than deregister the UE from the network.

Sorry, I think that's step 20. in R15.

[Conditional] old AMF to (V-)PCF: AMF-Initiated Policy Association Termination.
If the old AMF previously initiated a Policy Association to the PCF, and the old AMF did not transfer the PCF
ID(s) to the new AMF (e.g. new AMF is in different PLMN), the old AMF performs an AMF-initiated Policy
Association Termination procedure, as defined in clause 4.16.3.2, to delete the association with the PCF.

For UE_INITIAL_REGISTRATION and SUBSCRIPTION_WITHDRAW, it is fine to do AMF-Initiated Policy Association Termination directly. However, if it is REGISTRATION_AREA_CHANGE, it is possible that the new AMF reuses the associated PCF ID, which hence should not be terminated.
R15 spec mentioned the condition:

If the old AMF previously initiated a Policy Association to the PCF, and the old AMF did not transfer the PCF
ID(s) to the new AMF

R16 has clearer instructions:

If the old AMF has established an AM Policy Association and a UE Policy Association with the PCF(s), and the
old AMF did not transfer the PCF ID(s) to the new AMF (e.g. new AMF is in different PLMN), the old AMF
performs an AMF-initiated Policy Association Termination procedure, as defined in clause 4.16.3.2, and
performs an AMF-initiated UE Policy Association Termination procedure, as defined in clause 4.16.13.1. In
addition, if the old AMF transferred the PCF ID(s) in the UE context but the new AMF informed in step 10 that
the AM Policy Association information and UE Policy Association information in the UE context will not be
used then the old AMF performs an AMF-initiated Policy Association Termination procedure, as defined in
clause 4.16.3.2, and performs an AMF-initiated UE Policy Association Termination procedure, as defined in
clause 4.16.13.1.

For UE_INITIAL_REGISTRATION and SUBSCRIPTION_WITHDRAW, it is fine to do AMF-Initiated Policy Association Termination directly. However, if it is REGISTRATION_AREA_CHANGE, it is possible that the new AMF reuses the associated PCF ID, which hence should not be terminated.

I agree with that, however, free5GC currently doesn't utilize the PCF ID to select the PCF, therefore, I leave the TODO comments for it.
Should we complete the feature (searching PCF by using PCF ID) in this PR or open another PR for this feature?

I think it is fine to leave for a new PR. Lastly, please help to change the TODO comments (// TODO: It also needs to check if the PCF ID is tranfered to new AMF...) to the followings:

// For UE_INITIAL_REGISTRATION and SUBSCRIPTION_WITHDRAW, do AMF-Initiated Policy Association Termination directly. // TODO: For REGISTRATION_AREA_CHANGE, old AMF performs an AMF-initiated Policy Association Termination // procedure if the old AMF has established an AM Policy Association and a UE Policy Association with the PCF(s), // and the old AMF did not transfer the PCF ID(s) to the new AMF. (Ref: TS 23.502 - 4.2.2.2.2)

ss920386 · 2023-09-15T09:21:27Z

internal/sbi/httpcallback/api_handle_dereg_notification.go

+		ue.SdmSubscriptionId = ""
+	}
+
+	if doUecmDereg {


Will this dereg the new registered UE after new AMF's when the dereg reason is UE_INITIAL_REGISTRATION?

Yes, it will

So should UE_INITIAL_REGISTRATION also exclude UeCmDereg?

From my understanding, if the reason is UE_INITIAL_REGISTRATION the consumer NF should be during the initial registration procedure. Therefore I think the consumer NF should execute the UECM Deregistration.
For example, let's say the new AMF has completed the UECM Registration but has not completed the initial registration procedure yet. If it receives the deregistration notification from UDM, I think the reason may be UE_INITIAL_REGISTRATION.
Another example is that the old AMF has completed the initial registration procedure and the new AMF is during the initial registration procedure. The UDM sends a deregistration notification with the reason SUBSCRIPTION_WITHDRAWN to the old AMF.
If I was wrong, please correct me.

According to 23.502 4.2.2.2.2, I think only the old AMF receives UECM_DeregistrationNotification during the initial registration, and I think UE_INITIAL_REGISTRATION is the only dereg reason that fits it🤔. (Or did you see any other parts of specs mentioning this part?)

For the reason SUBSCRIPTION_WITHDRAWN, I saw it mentioned in 4.2.2.3.3 Network-initiated Deregistration.

[Conditional] If the UDM wants to request the immediate deletion of a subscriber's RM contexts and PDU
Sessions, the UDM shall send a Nudm_UECM_DeregistrationNotification (SUPI, Access Type, Removal
Reason) message with Removal Reason set to Subscription Withdrawn to the registered AMF. The Access Type
may indicate 3GPP Access, non-3GPP Access or both.

Indeed, I'm not quite sure whether the cited parts include all cases for SUBSCRIPTION_WITHDRAWN, so feel free to open more discussions if you have any concerns🙏

Hi @YouShengLiu @ss920386
I think @ss920386's concern is right, those service operations should be mutually exclusive.

If that is the case, another concern is that if UDM does deregister the AMF when it sends UECM_DeregistrationNotification in our UDM implementation. (It is possible that our UDM simply sents UECM_DeregistrationNotification to AMF without handling the related contexts.)

For the current implementation in UDM, it will use the Amf3GppAccessRegistration from the new AMF to replace the Amf3GppAccessRegistration from the old AMF.
Then, the UDM will send UECM_DeregistrationNotification to AMF.
Amf3GppAccessRegistration is the context related to the Nudm_UECM for AMF registration for 3GPP access.

@YouShengLiu How about SUBSCRIPTION_WITHDRAW?

Although the current UDM sends the dereg notification with the reason SUBSCRIPTION_WITHDRAW, based on our discussion, I think it should be modified to UE_INITIAL_REGISTRATION.
Therefore, the current UDM would not have the possibility to send the dereg notification with the reason SUBSCRIPTION_WITHDRAW.
As for further development, we may implement another API to handle this situation (e.g. OAM) or it will be triggered from UDR when the subscription data is removed.

tim-ywliu · 2023-09-15T13:48:11Z

internal/sbi/httpcallback/routers.go

+	{
+		"AmfHandleDeregistrationNotification",
+		strings.ToUpper("Post"),
+		"/amf-implicit-deregistration/3gpp-access/:ueid",


modify as below:

/deregistration/:access/:ueid

add query parameter type=implicit

real URI will be like:
{URL}/deregistration/3gpp/imsi-208930000000001?type=implicit

Sorry, I forgot the request body of the deregistration notification contains the access type.
Therefore, It should not put the access type into the URI.

@YouShengLiu
Sorry, no need use type queryParam, amf can determine to do implicit dereg by deregReason in DeregistrationData.

tim-ywliu · 2023-09-15T14:02:12Z

internal/sbi/httpcallback/api_handle_dereg_notification.go

+
+	if doUecmDereg {
+		// Use old AMF as the backup AMF
+		backupAmfInfo := models.BackupAmfInfo{


Now there is no config for backup amf, so don't fill backup amf info to UDM for now.

Ok, I will remove it.

internal/sbi/consumer/ue_context_management.go

tim-ywliu · 2023-09-29T07:24:50Z

internal/sbi/httpcallback/api_handle_dereg_notification.go

-					ue.GmmLog.Errorf("Release SmContext Failed Problem[%+v]", problemDetails)
-				} else if err != nil {
-					ue.GmmLog.Errorf("Release SmContext Error[%v]", err.Error())
+	if deregType == "implicit" {


The implicit and explicit dereg procedures are almost same, only difference is nas msg sent in explicit dereg. The procedures before ue.Remove() can move out this if.

The implicit and explicit dereg procedures are almost same, only difference is nas msg sent in explicit dereg. The procedures before ue.Remove() can move out this if.

OK

tim-ywliu · 2023-10-25T11:28:55Z

internal/sbi/httpcallback/api_handle_dereg_notification.go

+	// TS 23.502 - 4.2.2.2.2 General Registration - 14e
+	// TODO: (R16) If old AMF does not have UE context for another access type (i.e. non-3GPP access),
+	// the Old AMF unsubscribes with the UDM for subscription data using Nudm_SDM_unsubscribe
+	if ue.SdmSubscriptionId != "" {


@ianchen0119 check udm implementation to make sure old amf will not unsubscribe new amf's subscription

tim-ywliu · 2023-10-25T11:30:17Z

internal/sbi/httpcallback/api_handle_dereg_notification.go

+
+	// TS 23.502 - 4.2.2.2.2 General Registration - 20 AMF-Initiated Policy Association Termination
+	// For UE_INITIAL_REGISTRATION and SUBSCRIPTION_WITHDRAW, do AMF-Initiated Policy Association Termination directly.
+	if ue.PolicyAssociationId != "" {


@ianchen0119 check pcf implementation to make sure old amf will not unsubscribe new amf's ampolicy association

* It is a callback function for handling the Deregistration Notify from UDM.

* if amfue has completed UeCmRegisteration, RemoveAmfUe should be done in AmfHandleDeregistrationNotification.

* currently only consider the 3GPP access type

* Use API to replace the duplicate code. * Add BackupAmfInfo to the AmfUe structure for UeCmDeregistration. * Expose the function "PurgeSubscriberData" from "gmm/common" package for purging the subscriber data with the specified access type.

* (R15) Old AMF always execute Nudm_SDM to unsubscribes with UDM. (don't consider access type) * Old AMF will determine whether to execute Nudm_UECM de-registration with UDM based on the dereg cause.

* Old AMF will delete the AM policy with PCF

* Modify DeregCallbackUri to differentiate the access type. * Modify the file name for consistency.

* Modify the structure of the handler function. * Add query parameter to differential the deregistration type is implicit or explicit.

- Remove the query parameter - DeregistrationNotifcation and UECM_Deregistration are mutually exclusive

YouShengLiu and others added 5 commits July 13, 2023 12:31

Add IE, universal time, in the configuration update command message:

375383a

* Add TimeZone field in the AMFContext.

Fix bug: the format of time zone is wrong

0bc5ed3

Modify BuildConfigurationUpdateCommand

0299827

Update go module

f99bc6d

Merge branch 'free5gc:main' into main

77cd10c

YouShengLiu mentioned this pull request Aug 17, 2023

Send Deregistration Notify before UDM modifies the UE context free5gc/udm#25

Merged

ianchen0119 reviewed Aug 24, 2023

View reviewed changes

Merge branch 'free5gc:main' into main

a765317

ianchen0119 approved these changes Aug 29, 2023

View reviewed changes

ianchen0119 requested changes Sep 12, 2023

View reviewed changes

ss920386 reviewed Sep 12, 2023

View reviewed changes

Merge branch 'free5gc:main' into main

05b0cef

YouShengLiu requested a review from ss920386 September 15, 2023 05:30

ss920386 reviewed Sep 15, 2023

View reviewed changes

tim-ywliu reviewed Sep 15, 2023

View reviewed changes

internal/sbi/consumer/ue_context_management.go Outdated Show resolved Hide resolved

YouShengLiu requested a review from ss920386 September 22, 2023 08:14

tim-ywliu reviewed Sep 29, 2023

View reviewed changes

ss920386 approved these changes Oct 19, 2023

View reviewed changes

ianchen0119 approved these changes Oct 25, 2023

View reviewed changes

tim-ywliu reviewed Oct 25, 2023

View reviewed changes

YouShengLiu and others added 6 commits October 28, 2023 16:02

Merge branch 'free5gc:main' into main

8ae1897

Complete the HTTPAmfHandleDeregistrationNotification

bde9459

* It is a callback function for handling the Deregistration Notify from UDM.

Modify RegistrationStatusUpdateProcedure:

2c3ff59

* if amfue has completed UeCmRegisteration, RemoveAmfUe should be done in AmfHandleDeregistrationNotification.

Modify RegistrationStatusUpdateProcedure:

39ecf3d

* currently only consider the 3GPP access type

Modify HTTPAmfHandleDeregistrationNotification

d713f96

* (R15) Old AMF always execute Nudm_SDM to unsubscribes with UDM. (don't consider access type) * Old AMF will determine whether to execute Nudm_UECM de-registration with UDM based on the dereg cause.

YouShengLiu added 5 commits October 28, 2023 16:19

Modify HTTPAmfHandleDeregistrationNotification

d1b9609

* Old AMF will delete the AM policy with PCF

Modify UeCmRegistration

6b1b1ad

* Modify DeregCallbackUri to differentiate the access type. * Modify the file name for consistency.

Modify HTTPHandleDeregistrationNotification

e832b89

* Modify the structure of the handler function. * Add query parameter to differential the deregistration type is implicit or explicit.

Modify DeregistrationNotificationProcedure

281fb39

- Remove the query parameter - DeregistrationNotifcation and UECM_Deregistration are mutually exclusive

Leave TODO comment about policy association termination.

db09490

tim-ywliu approved these changes Oct 28, 2023

View reviewed changes

tim-ywliu merged commit aebc9fc into free5gc:main Oct 28, 2023
2 checks passed

Feature/implicit deregistration #107

Feature/implicit deregistration #107

Conversation

YouShengLiu commented Aug 17, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

YouShengLiu Sep 12, 2023 • edited Loading

Choose a reason for hiding this comment

ianchen0119 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ss920386 Sep 12, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ss920386 Sep 27, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

YouShengLiu Sep 12, 2023 •

edited

Loading

ss920386 Sep 12, 2023 •

edited

Loading

ss920386 Sep 27, 2023 •

edited

Loading